Stop the lint pipeline from reporting issues it re-creates itself - #5788

Preserve whitespace linting for standalone HBS files

This disables the rule for every template-lint invocation, including .hbs submissions. In lintOne, .hbs is absent from ESLINT_EXTENSIONS, so it never passes through the Prettier step that motivates this exception, but it is included in TEMPLATE_LINT_EXTENSIONS; consequently genuine whitespace-for-layout violations in standalone templates are now silently accepted. Apply the override only for .gts/.gjs inputs that were formatted, or retain a separately configured linter for .hbs.

Useful? React with 👍 / 👎.

[Claude Code 🤖] The routing half of this is correct and I reproduced it: .hbs is in TEMPLATE_LINT_EXTENSIONS but absent from ESLINT_EXTENSIONS, so lintOne never runs prettier over it, and driving lintSource over <div>\n <span>A &nbsp;&nbsp; B</span>\n</div> reports no-whitespace-for-layout on main and reports nothing on this branch.

The remedy doesn't follow, though, because the premise it rests on — that prettier's wrapping is what motivates the exception — isn't true for .gts either. no-whitespace-for-layout trims each line of a text node before matching, so prettier's newline-plus-indent is invisible to it; on main, a long plain-space text node that prettier wraps reports nothing, while a short unwrapped line containing    reports the rule. The trigger is   adjacency in the authored text, independent of formatting. Details and the full fixture table are in my review comment on initTemplateLinter in packages/runtime-common/tasks/lint.ts.

So the rule was never conditioned on the prettier pass, and gating the override on "inputs that were formatted" would split behavior along an axis the rule doesn't respond to: two files with identical text would lint differently based only on extension. Once the justification is restated in the terms that actually hold —   runs are deliberate visual spacing in realm content, the rule has no autofix, and its message doesn't identify the offending characters — disabling it uniformly across .gts/.gjs/.hbs is the consistent choice rather than an oversight. My read is that no code change is needed here, only the comment rewrite I've asked for separately.

Generated by Claude Code

[Claude Code 🤖] This comment states a mechanism that doesn't hold: prettier's wrapping never triggers no-whitespace-for-layout. The disable itself may well be right, but this explanation is the only thing the next editor will read, and it will send them to fix the wrong thing (reorder the pipeline, re-enable the rule "now that prettier runs later", etc.).

What the rule actually does. ember-template-lint/lib/rules/no-whitespace-for-layout.js visits each TextNode, splits its source on \n, trims every line, and only then tests /(( )|( ))(( )|( ))/:

let lines = source.split('\n');
for (let line of lines) {
  // ignore whitespace at the start and end of the line
  let trimmed = line.trim();
  // check for two ` ` or ` ` in a row
  let matches = trimmed.match(/(( )|( ))(( )|( ))/g);

Prettier's wrap contributes exactly a newline plus leading indentation — both removed by that trim. What the regex matches is two adjacent “space or  ” tokens inside a trimmed line, which is a property of the authored text, not of the formatting.

Verified against the real pipeline. I drove lintSource from this file (so the full ESLint → prettier → ESLint → template-lint chain, host config, ember-template-lint 7.9.3) on main, i.e. with the rule still enabled:

Row 1 is the direct disproof of "prettier wraps → the rule flags the wrap": the wrap happened and nothing was reported. Row 2 shows the rule firing with no wrapping anywhere in play. Row 4 shows the one kind of whitespace prettier does touch, and it resolves the rule rather than fighting it.

"An error that no edit can clear" is also not the case. Rewriting the run so no   sits next to a space — ...MY HOMEPAGE HOT SITE AWARD WINNER BEST VIEWED... — lints clean, and prettier still wraps that line, so the edit survives the formatter. What does not survive is a whitespace-only edit such as collapsing the wrapped text back onto one line: prettier restores it byte-identically. So the loop you reproduced is real, but its cause is that the rule's message — Excess whitespace detected, anchored on the whole text node — never says which whitespace it means, and the model kept picking the one edit class the formatter undoes.

The way out. Keep the disable, and justify it on the ground that actually holds:   runs are deliberate visual spacing in card content, the rule has no autofix, and its diagnostic doesn't identify the offending characters, so it produces errors the patch loop can't act on. Something like:

  // Host's config, minus rules that are noise for realm content.
  // no-whitespace-for-layout flags any two adjacent " " / " " tokens in a
  // trimmed line of a text node. Card content uses   runs deliberately for
  // visual spacing, the rule has no autofix, and its message ("Excess whitespace
  // detected", anchored on the whole text node) doesn't identify which
  // whitespace it means — so it hands the patch loop an error it can't act on.

Scope: regression introduced by this PR (the comment is new), non-blocking for behavior. I'd still hold merge on it — a wrong mechanism in a comment costs more than the missing comment would.

Confirmation, separately: the config-object swap itself is safe. I instantiated new TemplateLinter({ workingDir: HOST_PKG }) and the new { workingDir, config } form side by side and compared them on eight fixtures. The full extends chain survives: the @cardstack/template-lint plugin rules still load and fire (no-data-test-selector, require-scoped-style, no-unused-block-params-except-underscore), core recommended rules still fire (no-triple-curlies, no-forbidden-elements, no-curly-component-invocation), and rules the plugin config turns off stay off (require-button-type). hostRequire('./.template-lintrc.js') resolves against the host package directory as intended, and an existing {{! template-lint-disable no-whitespace-for-layout }} in realm content does not become an unused-directive error. The one standing condition: this hard-codes the config filename, so moving host to .template-lintrc.cjs or a package.json key would break it silently rather than at a config-resolution error.

Generated by Claude Code

[Claude Code 🤖] This test passes for a different reason than its name and comment claim, so it pins a narrower contract than the change actually makes.

The test does fail on main and pass here, so it guards something real. But the wrap it asserts on line 652 isn't why no-whitespace-for-layout fired: as detailed in the comment on initTemplateLinter in packages/runtime-common/tasks/lint.ts, the rule trims each line before matching, so prettier's wrap is invisible to it — the     runs already present in longText are what fire it. I confirmed on main that a long text node with plain spaces and no   gets wrapped by prettier and reports nothing, while <span>A &nbsp;&nbsp; B</span> on a single short line reports no-whitespace-for-layout without any wrapping.

Two consequences:

1. The name mis-teaches. does not flag the whitespace prettier introduces by wrapping long text describes a behavior that was never there to remove. Someone later reading this test will carry the same wrong model of the pipeline that the lint.ts comment encodes.
2. The real contract is broader than what's pinned. The change disables the rule for every template-lint invocation, not just wrapped-text cases. Nothing in the suite would notice if a future edit narrowed the disable to some formatter-introduced subset, because this fixture would keep passing either way.

The way out. Rename to what it checks — something like no-whitespace-for-layout is not reported for realm content — drop the wrap assertion (or keep it, but stop labelling it as the cause), and add a second fixture with the   run on a short, prettier-stable line. That second case is the one that pins the actual scope: it fails on main for exactly the same reason with no wrapping involved.

While you're in here, a .gts fixture that still trips a different template-lint rule would be worth adding — the extends chain surviving the config-object swap is the main risk in this change and nothing in the suite covers it. <template><div>{{{this.html}}}</div></template> (no-triple-curlies, core recommended) and <template><style>.a { color: red }</style></template> (require-scoped-style, the @cardstack/template-lint plugin) both fire through this pipeline; I verified both against the new linter. A plugin-rule case in particular would catch a future config regression that silently drops the plugin.

Scope: follow-up-sized, but it's in this PR's own new test, so it's cheap to do here. Non-blocking.

Generated by Claude Code

[Claude Code 🤖] The flag infers "the formatter reverted it" from "the content is unchanged", and those come apart in two reachable cases. Both are minor; the fix is two lines and makes the code state the invariant instead of inheriting it.

Why the premise holds today. ApplySearchReplaceBlockTool.run throws SEARCH_PATTERN_NOT_FOUND when resultContent === input.fileContent && searchPattern !== '', so a single block that changes nothing lands as failed, not applied. That's what makes "an applied patch always changed the pre-lint content" true — but it's true by a rule enforced in a different file, with nothing at either end noting the dependency. If that guard is ever relaxed (a debatable one: it also rejects a legitimate patch whose only effect prettier would have made anyway), this branch starts lying without any test noticing.

Where it comes apart now.

• Non-lintable targets. isLintableFile matches only /\.(gts|ts)$/, so .json card instances — a common patch target — never reach lintAndFix. Same for any .gts whose patched content is blank (patchedCode.trim() !== '' gate above). In those paths no formatter ran at all, yet a content-equal outcome would tell the model "The automatic formatter reverted the applied changes".
• Blocks that cancel. Two blocks in one codeBlocks array where the second undoes the first each change content individually, so both report applied and neither throws, but patchedCode === sourceContent.

Neither is common, and in both the skip-the-save half is the right call. It's the message that misleads — and it's aimed at a model that will act on it.

The way out. Capture the pre-lint content and require that it differed, so the flag means what its name says:

      let preLintCode = patchedCode;
      if (patchedCode.trim() !== '' && this.isLintableFile(fileUrl)) {
        let lintResult = await this.lintAndFix(fileUrl, patchedCode);
        patchedCode = lintResult.output;
        lintIssues = lintResult.lintIssues ?? [];
      }

      let revertedByFormatter =
        sourceContent !== '' &&
        preLintCode !== sourceContent &&
        patchedCode === sourceContent;

Test coverage. The new branch has none. packages/host/tests/integration/tools/patch-code-test.gts already installs an adapter.lintStub, so a stub that returns the request body's pre-patch content gives you the case directly: assert the file on the realm is untouched, that lintIssues carries the new sentence, and — the part that actually matters for the loop — that results[0].status is still applied. That last assertion is worth pinning explicitly, because gatherPatchedFiles in packages/runtime-common/ai/prompt.ts skips any result whose status isn't applied; if this branch ever started reporting failed, the message would be assembled into the prompt and then dropped, and the backstop would silently stop working.

Scope: regression-adjacent (the misleading message is new), non-blocking. The test gap is the part I'd most want addressed before merge.

Generated by Claude Code